Repository navigation
ci(process-daemon): stop pinning the protocol in the Windows smoke test - #61889
Conversation
There was a problem hiding this comment.
Looks good. I read the step on the PR head (CI-only, so nothing to run locally). The $LASTEXITCODE check after --version is still there, and nothing left in the step uses $version. Public API: unchanged (CI workflow only).
One thing to check for #61875: release-process-daemon.yml still pins PROTOCOL_VERSION: 7 and compares the --version output against it in several places. The protocol 8 bump will still need a workflow edit there, unless that pin is meant to stay in the release workflow. There is also a small suggestion inline about keeping the crate-version check.
There was a problem hiding this comment.
The earlier point is addressed: the step checks the crate version again and accepts any protocol number. I read the pattern against the --version format string in packages/process-daemon/src/client.rs, and the PowerShell quoting and escaping look right (no pwsh here to run it). Public API: unchanged (CI workflow only). Nothing new to flag.
Issue for this PR
Closes #
Type of change
What does this PR do?
The Windows smoke step in
check-process-daemon.ymlcomparedopencode-pty --versionagainst a hardcoded(protocol 7), so every protocol bump needed a workflow change (and workflow approval). It still checks that the binary reports the crate version, but now accepts any protocol number: the output must matchopencode-pty <crate version> (protocol <number>), the format printed inpackages/process-daemon/src/client.rs.Needed for #61875 (protocol 8), which then doesn't have to edit the workflow.
How did you verify your code works?
Checked the pattern against the binary's format string (
"opencode-pty {} (protocol {})"). The PowerShell isn't run locally (nopwshhere); CI on this PR runs the step on Windows.Checklist